Search for: All records

Abstract. Nitrous oxide (N2O), a potent greenhouse gas and ozone-destroying agent, is produced during nitrogen transformations in both natural and human-constructed environments. Wastewater treatment plants (WWTPs) produce and emit N2O into the atmosphere during the nitrogen removal process. However, the impact of WWTPs on N2O emissions in downstream aquatic systems remains poorly constrained. By measuring N2O concentrations at a monthly resolution over a year in the Potomac River Estuary, a tributary of Chesapeake Bay in the eastern United States, we found a strong seasonal variation in N2O concentrations and fluxes: N2O concentrations were larger in fall and winter but the flux was larger in summer and fall. Observations at multiple stations across the Potomac River Estuary revealed hotspots of N2O emissions downstream of WWTPs. N2O concentrations were higher at stations downstream of WWTPs compared to other stations (median: 21.2 nM vs 16.2 nM) despite the similar concentration of dissolved inorganic nitrogen, suggesting the direct discharge of N2O from WWTPs into the aquatic system or a higher N2O production yield in waters influenced by WWTPs. Since wastewater production has increased substantially with the growing population and is projected to continue to rise, accurately accounting for N2O emissions downstream of the WWTPs would better constrain the global N2O emissions. Efficient N2O removal, in addition to dissolved nitrogen removal, should be an essential part of water quality control in WWTPs. 

Automatic parallelizing compilers are often constrained in their transformations because they must conservatively respect data dependences within the program. Developers, on the other hand, often take advantage of domain-specific knowledge to apply transformations that modify data dependences but respect the application's semantics. This creates a semantic gap between the parallelism extracted automatically by compilers and manually by developers. Although prior work has proposed programming language extensions to close this semantic gap, their relative contribution is unclear and it is uncertain whether compilers can actually achieve the same performance as manually parallelized code when using them. We quantify this semantic gap in a set of sequential and parallel programs and leverage these existing programming-language extensions to empirically measure the impact of closing it for an automatic parallelizing compiler. This lets us achieve an average speedup of 12.6× on an Intel-based 28-core machine, matching the speedup obtained by the manually parallelized code. Further, we apply these extensions to widely used sequential system tools, obtaining 7.1× speedup on the same system. 

The open-source and community-supported gem5 simulator is one of the most popular tools for computer architecture research. This simulation infrastructure allows researchers to model modern computer hardware at the cycle level, and it has enough fidelity to boot unmodified Linux-based operating systems and run full applications for multiple architectures including x86, Arm, and RISC-V. The gem5 simulator has been under active development over the last nine years since the original gem5 release. In this time, there have been over 7500 commits to the codebase from over 250 unique contributors which have improved the simulator by adding new features, fixing bugs, and increasing the code quality. In this paper, we give and overview of gem5's usage and features, describe the current state of the gem5 simulator, and enumerate the major changes since the initial release of gem5. We also discuss how the gem5 simulator has transitioned to a formal governance model to enable continued improvement and community support for the next 20 years of computer architecture research.